“Led” is the past tense of “lead.”
L.E.D. Not L.E.A.D.
Example: “Fran, who leads the group, led the meeting.”
When professional publications get the small stuff wrong, it makes us less trusting about the big stuff. Trust in media is already at an all-time low. Don’t alienate liberal arts majors and obsessive compulsives. We may be the last readers standing.
Q.
A.
[I]n El Capitan B4, Apple decided to stop shipping Procmail, and with it, lockfile. It wasn’t deprecated and then removed… it was unceremoniously sent to the bit bucket. So, as of B4, scheduling in El Capitan broke.
REBUILDING iTunes library from scratch over two days got app working again. Fine use of lazy weekend.
Had to sacrifice all custom playlists dating back to 2002, including An Event Apart playlists and delivery room mix from Ava’s birth.
Playlists still exist on old iPod but can’t be copied from it back to iTunes. (All software I’ve tried freezes & fails.)
Playlists still exist as code snippets inside .itl file in old iTunes folder, but numerous trials prove iTunes can’t launch from that folder any more. Thus I can’t temporarily launch from old folder, export playlists, switch back to safe new folder, and import them, thereby saving them.
And iTunes can’t import old .itl files. I Googled. I tried anyway.
13 years of custom playlists. From before, during, and after my marriage. Including one my daughter called “princess music” and danced to when she was three. Gone.
But, really, so what? Over time we lose everything. This loss is nothing. Attachment is futile. Always move forward, until you stop moving.
Now we have something else to be thankful for. Nathan Smith of Sonspring has created a library that gives designers and developers “some measure of control over form elements, without changing them so drastically as to appear foreign in a user’s operating system.” Smith calls his new library Formalize CSS:
I’ve attempted to bridge the gap between various browsers and OS’s, taking the best ideas from each, and implementing what is possible across the board. For the most part, this means most textual form elements have a slight inset, and all buttons look consistent, including the
buttontag.
For more, including demos, options, screenshots, thanks, and the library itself, read Smith’s write-up at SonSpring | Formalize CSS. Hat tip and happy Thanksgiving to my good friend Aaron Gustafson for sharing this gem.
Free for use in all web projects, professional or personal, HTML5 Reset by Monkey Do! is a set of HTML5 and CSS templates that jumpstart web development by removing the styling native to each browser, establishing basic HTML structures (title, header, footer, etc.), clearing floats, correcting for IE problems, and more.
Most of us who design websites begin every project with bits and pieces of this kind of code, but developer Tim Murtaugh, who created these files and who modestly thanks everyone in the universe, has struck a near-ideal balance. In these lean, simple files, without fuss or clutter, he manages to give us the best-practices equivalent of everything but the kitchen sink.
Tim Murtaugh sits beside me at Happy Cog, so I’ve seen him use these very files (and earlier versions of them) to quickly code advanced websites. If you’re up to speed on all the new hotness, these files will help you stay that way and work faster. If you’re still learning (and who isn’t?) about HTML5, CSS3, and browser workarounds, studying these files and Tim’s notes about them will help you become a more knowledgeable web designer slash developer. (We need a better name for what we do.)
My daughter calls Mr Murtaugh “Tim the giant.” With the release of this little package, he earns the moniker. Highly recommended.
And so do my iPhone and your iPad. All it took was a bit o’ the old Richard Fink syntax and a quick drive through the Font Squirrel @Font-Face Kit Generator (featuring Base 64 encoding and SVG generation) to bring the joy and wonder of fast, optimized, semi-bulletproof web fonts to Safari, Firefox, Opera, Chrome, iPhone, and Apple’s latest religious device.
Haven’t checked IE7, IE8, IE9, or iPad yet; photos welcome. (Post on Flickr and link here.)
What I learned:
? Even if manufacturer supplies “web font” versions with web license purchase, it’s better to roll your own web font files as long as this doesn’t violate the license.
So I’ve wanted to use a condensed, bold Franklin typeface for my site’s headlines since, well, forever. So I bought Fontspring’s fine Franklin Gothic FS Demi Condensed and licensed it for @font-face use for a mere $2.99, an incomparable value.
It looks great in Safari, Chrome, and Firefox, but not so nice in the latest version of Opera, where it resembles the inside-out test monkey in Cronenberg’s “The Fly.” (Okay, okay, it looks like a ransom note, but the monkey simile was more picturesque.)
And this, my friends, is why Typekit exists. Because even when you find a great font that’s optimized for screen display and can be licensed for CSS @font-face use, guess what? There is almost always some glitch or bug somewhere. And Typekit almost always seems to find and work around these bugs. It’s the kind of grueling task designers hate dealing with, and Typekit’s team loves solving.
If this were a client site, I’d switch to Typekit, or try licensing a different vendor’s Franklin, or (if neither of those options proved satisfactory) dump web fonts altogether and use Helvetica backed by Arial instead. But as this is zeldman.com, I’d rather nudge my friends at Opera to look into the problem and fix it. This will make browsing zeldman.com in Opera a somewhat weird experience, but hopefully it will help all Opera users in the long run.
Update: Problem solved. See Opera Loves My Web Font.
It’s been years (or is it weeks?) since something odd, implausible, and inexplicable happened to one or more of my Apple computers that doesn’t happen to anyone else’s. You know you want to hear this.
So yesterday morning I’m in my hotel, finishing some work on my laptop before leaving for the airport, when MobileMe alerts me that in order to sync the bookmarks on my laptop, it will need to delete some and add some. I click OK. A few seconds later, I have no bookmarks in Safari.
That’s strange, but it’s a bit liberating, too. I feel lighter. That kink in my neck is gone.
Heck, I can re-create the few bookmarks I really need and do without the rest, right? (Besides, I imported my Safari bookmarks into Chrome a few weeks ago, and I sync Chrome bookmarks via Google, so the bookmarks aren’t really gone, they’re just gone from Safari.)
I re-create five or six bookmarks in my laptop’s Safari bookmarks bar, close my laptop, and fly home.
Here’s where it gets weird.
At home, after midnight, sleepless, jetlagged, I turn on my iMac. MobileMe wants to sync my bookmarks. It says it will delete quite a few of them and create a handful of new ones. There is no option to send my iMac’s bookmarks to MobileMe instead. There is no option not to sync. I can skip sync for now, but eventually I’ll have to sync, and that means I’ll have to let MobileMe wipe my many old Safari bookmarks off all my computers. No sense delaying the inevitable.
I click OK.
My old bookmarks are gone, but the new ones I created on my laptop have not been sync’d. I have no bookmarks.
I start re-creating them from scratch, and as I create them, they disappear.
I create a Flickr bookmark. It works. I create a zeldman.com admin bookmark. When I look up, the Flickr bookmark has disappeared. I create a Twitter bookmark. When I look up, the zeldman.com admin bookmark has disappeared. A moment later, the Twitter bookmark has disappeared.
I begin quitting Safari immediately after creating a bookmark (in order to force Safari to save it). This seems to work. When I re-start Safari, the bookmark I just created has been saved. I do this six times in order to create and save the few bookmarks I really need in order to work.
I don’t bother re-creating the dozens of JavaScript bookmarklets I use daily. I figure I can do those in the morning. I verify that Safari now contains six bookmarks. I run a backup via SuperDuper and go to bed.
In the morning, my bookmarks bar is blank again. Overnight, all my bookmarks have disappeared.
It can’t be from syncing via MobileMe, because the computer should have gone to sleep as soon as the backup finished (and it was asleep when I woke up this morning).
At this point all I can figure is that Apple wants me to switch to Chrome.
Snow Leopard plus FontExplorer X equals screwed-up fonts in Firefox (especially Helvetica).
Update: Buying FontExplorer X Pro and clearing font caches also solves the problem. (The problem is with Apple’s fonts, not with Firefox or FontExplorer X, but it takes mediation to fix it.)
For those who couldn’t be there, and for those who were there and seek to savor the memories, here is An Event Apart Chicago, all wrapped up in a pretty bow:
Note: Comment posting here is a bit wonky at the moment. We are investigating the cause. Normal commenting has been restored. Thank you, Noel Jackson.
Short URL: zeldman.com/?p=2695
Found in my in-box on this gloriously muggy morning:
Typical day.
Firefox gurus, a page demonstrating the Firefox long content bug has been created for your browser fixing pleasure. Kindly visit the test page using Firefox 3.0 and Firefox 3.5 for Windows (and possibly also for Linux). The following defects should be evident:
View the same page in Safari 3+, Opera 9+, or IE7/8, and compare. In the other browsers, all comments are displayed, the footer is displayed, and the content form is viewable and displays correctly. How often does Firefox compare unfavorably with some of these browsers? Hardly ever. Which is precisely why you want to fix it. (That, and you’d like your users to be able to view all the content on a page, not just some of the content.)
The test page is identical to this 2 July post, with comments frozen as of 9 July 2009, and with the site’s original CSS, which revealed the long content bug in Firefox.
A subsequent 8 July post documents the steps I and two other developers took in order to isolate this bug in Firefox, and the CSS workarounds (suggested by two of the site’s readers) which have since been put in place to cover up for this defect in Firefox. The thread also explains what we changed in the CSS to enable Firefox users to read long content on the site.
The CSS cover-up enables Firefox users to read all the content on long pages, but at a cost: there is a flash of red background during slow load times. And, obviously, it’s better to fix Firefox than to create somewhat flawed CSS workarounds that slightly diminish the experience for all users of the site.
Thanks for your help! Let me and this site’s readers know how we can assist you. And remember, please use the test page (not this page or any other page of the site) to isolate the bug in Firefox.
[tags]firefox, browser, bug, firefox3, firefox3.5, windows, linux, bugs, buggery, debugging, demo, testpage, mozilla[/tags]
There’s good news and bad news. The good news is that Firefox 3.0 and 3.5 for Windows no longer cut long pages of this site in half, hiding 50% or more of the pages’ content, including the footer, because of a newly discovered bug in Firefox (discovered by this site’s layout).
The bad news is that the price of the “fix” is an annoying flash of reddish-orange background. When you first load a page in any browser, rather than the main content’s off-white background area, you instead see the text against a reddish-orange background, obscuring words (including the drop cap), disrupting user experience, and raising doubts about the professionalism of the site and thus of the opinions it expresses.
With the annoying flash of colored background, everyone who reads this site suffers. But without it, Firefox 3/3.5 cuts long pages in half. Until Firefox fixes the bug, all readers of this site will experience what I’ll label “the Flash of wrongly styled background color.” (Note: although the browser is still broken, the color flash has since been “fixed.” Impatient ones, skip ahead to the 9 July update. Narrative fans, keep reading.)
Here’s the story.
My 2 July post, XHTML DOA WTF, has thus far received 194 comments. Firefox users told me the thread “died” after comment #44049 in Firefox 3 and 3.5 for Windows. The problem also later surfaced on In Defense of Web Developers, written yesterday morning just prior to my surgery. Let’s stick with the 2 July post, though, which is where we did our Q&A.
W3C and WDG validation services both indicated that there was an error on the page, but neither validator could explain it.
I next spent two hours of an insanely busy pre-surgery day unsuccessfully attempting to manually track down UTF errors in comments that no validation service was able to pointpoint. I had to apologize to colleagues and clients to whom I owed work, since the quest to make my personal site legible and usable to Firefox users took precedence over paying work in my sad little mind. (Call it a mark of the high esteem in which I hold Firefox; also call it a concern for readers.)
Automattic’s designer/developer (and my friend) Noel Jackson then took over for me and was eventually able to locate a single UTF error in a Japanese pingback. Or so it seemed.
WordPress, the power behind this site, is supposed to convert illegal UTF-16 to legal UTF-8, and we thought it had done so. Nevertheless, the only validation service to have claimed anything semi-coherent said otherwise. To solve the problem required brute force: we deleted the entire Japanese comment. To the clients and colleagues to whom I owed work I was unable to finish while tracking down a Firefox bug, I now also owed an apology to a Japanese blogger. Personally, I blamed Firefox for ludicrously Draconian error handling, but at least I thought we had “solved” the needless problem raised by such behavior.
I owe Firefox an apology. Draconian error handling of impossible-to-trace possible UTF errors was not the cause of its failure to display pages correctly. Inability to parse valid CSS on long pages was the actual cause.
Although my page now validated, Firefox still cut it off at the waist. Thanks to this bug, users of Firefox—many of whom care greatly about web standards (it’s one reason so many developers choose Firefox)—were unable to read more than half the comments about XHTML 2 and HTML 5 from their fellow standardistas. They were also unable to post comments or view the footer (thus making them unable to view other content on this site, as well as third-party site highlighted in the footer). This was a win for nobody, except maybe Microsoft, Opera, and Safari. And, like I said, we like Firefox and people who use it. Back to the drawing board.
Nikolay Bachiyski, a lead developer at Automattic, then conducted a series of tests:
Valid CSS was somehow to “blame” for Firefox’s inability to show a long page without hiding half the content.
You may ask why I didn’t discover this problem during the building and testing of my site’s redesign. You might even ask why my readers didn’t discover it (since I beta tested the redesign at several stages). The answer is simple. I never tested a dummy blog post with nearly 200 comments. It didn’t occur to me that more than 40 comments would be necessary to test whether valid CSS and XHTML would work in good modern browsers, let alone in one as excellent as Firefox.
Michel Bozgounov and Kyle Weems then proposed a simple CSS fix:
div#wrapper {overflow: visible;}
My friend Noel implemented the CSS fix while I was unconscious and having stuff cut out of me.
It works, and I thank all these gentlemen. But it has the unfortunately side-effect of inflicting a flash of reddish-orange background on the page until most or all content has loaded. (I had previously spent over two weeks eliminating that flash of background.) And it does this in all browsers (or nearly all), not just Firefox. To force Firefox to display all content on a page, I have to force every other browser to flash red before it shows content.
Obviously, it’s vital that Firefox users be enabled to read and comment on long or popular posts. But there must be a better way than deforming the CSS. And there is a better way: namely, a Firefox bug fix.
Our friends at WordPress have contacted our friends at Mozilla, so we are hopeful that this will be fast-tracked. Mozilla friends, call on me to help at any time.
With the addition of 1000px of min-height to #wrapper, the reddish-orange flash has been eliminated, at least in pages that load quickly. (On long pages, or with slow connections, the reddish-orange background remains painfully visible until the page finishes loading.) Read more about this CSS adjustment. Note that adding CSS workarounds is not the same thing as fixing browser bugs. (Indeed, CSS workarounds may retard browser development by removing the problem so it never gets fixed.)
As I am not entirely satisfied with this CSS workaround (despite my gratitude to its authors) and as I do not want Mozilla’s engineering wizards to be unable to fix Firefox because of changes to my CSS, I have posted a Firefox test page using the site’s original (perfectly fine, background-flash-less) CSS, and a page explaining the Firefox test page.—JZ
[tags]browser, bugs, Firefox3, Firefox3.5, Firefox/Windows, browsers, firefoxbugs[/tags]
Robert Black was right. OS X 10.5.7 adversely affects the internal heat management of some iMacs (and apparently also some MacBooks), causing the machines to overheat. Overheating, in turn, leads to such problems as freezes during iCal sync; freezes during iTunes sync; and the inability of attached hard drives to complete a backup.
I confirmed this by installing smcFanControl and watching my Mac get hotter and hotter as it tried to complete a SuperDuper backup. Disk Utility confirmed nothing was wrong with the attached drive. Swapping cables proved a faulty cable was not to blame for previous failed backups. Maddeningly, the backup got within 4GB of completion before locking up due to the overheating of my iMac.
Not every iMac or MacBook is affected. It probably varies by factory run and by model. (My MacBook Pro, for instance, is fine.) Third-party stuff and Migration vs. Tabula Rasa System Install seems to have no bearing on whether or not your Mac will choke on the update.
Since even running smcFanControl at settings recommended by Robert Black and others doesn’t cool the iMac enough to finish a backup or verify the quality of the attached drives, it may not make sense to replace my external hard drives (as new drives will likely also fail as the iMac overheats during backup).
With smcFanControl in place, I can use my iMacs but not back them up.
Apple needs to release an update that fixes the hardware problems this one created.
(And someone else needs to install it before I do.)
[tags]OSX10.5.7, bugs, Apple, Macintosh, update[/tags]
